What

Add tests/integration_ws_rate_limit.sh (+ a CI step) that drives real traffic to prove the per-IP events_per_minute / queries_per_minute throttles actually fire.

Why

The connection limit is covered (integration_ws_idle_reclaim.sh, 429), but the event/query rate limits were untested. handler.zig sends ["OK",id,false,"rate-limited: too many events"] (:271) and ["CLOSED",sub,"rate-limited: too many queries"] (:456) and bumps metrics.rateLimited() on the throttle path — none of it exercised.

How

The rejections are sent over a live connection (a unit test can't see them), so the test drives real traffic and reads the throttle back from the Prometheus counters that increment only on the rate-limit path:

• Burst BURST=8 valid, uniquely-tagged kind-1 events at LIMIT=3 (so a rejection can only be the rate limit, never a bad sig / duplicate / disallowed kind). Assert the first few are accepted, the excess rejected, and wisp_rate_limited_total rose by the throttled count.
• Burst REQs and assert wisp_query_rate_limited_total rose.

The token bucket starts full and refills at LIMIT/60/sec (~negligible over the ~1-2s burst); the assertions allow one refill token of slack (>= BURST-LIMIT-1) so a slow runner can't flake.

CI starts a dedicated relay with WISP_EVENTS_PER_MINUTE=3 WISP_QUERIES_PER_MINUTE=3 on port 7787 (mirrors the idle-reclaim step); requires the noz client the suite already builds.

Verification

Ran locally against zig build wisp + noz v0.2.1: 4/4 assertions pass, stable across 3 runs. Negative control (relay started with limits 100000, throttle effectively off): the test fails (0 throttled) — so it genuinely guards the behavior.

Addresses privkeyio/keep-node#11 (the wisp-side rate-limit coverage tracked as keep-node-h3o).